Modem systems complexity is far greater than the capacity of any single individual. A typical system, such as big as an aircraft or as small as a cell-phone, is designed by teams of specialists in some concurrent form. Such teams may include concept engineering, system architects, hardware, software and mechanical engineering teams, manufacturing, reliability, and testing and field service experts among others. Each specialist team typically has its own workflow and set of tools. Furthermore, portions of the design process are often outsourced, creating a situation where the various specialists are geographically dispersed and are employed by different companies.
All these teams of specialists need to have a consistent and coherent view of the requirements, the design and the work plans. Design concerns typically cut across multiple disciplines. Consider for example an aircraft design case where the customer requests a particular feature, such as an entertainment sub-system, to be installed. This request for a particular feature may, however, impact power requirements, alter the weight, require additional software, hardware, and mechanical interfaces, and pose new manufacturing, reliability and field service challenges. Because of this interdependency, a design change by any one specialist typically perturbs the design of the whole system.
For the design to converge quickly, each specialist needs to understand the effects of a design change on the overall system and needs to communicate the change in unambiguous terms to the rest of the design team. This need is not met by today's design environment for several reasons. For example, the specification, architecture, and planning information is typically distributed as text documents and engineering drafts. Such documents are open to interpretation, often subjective, and may contain ambiguities and contradictions. Moreover, formal engineering models are domain specific and are not shared between specialists. The software team, for example, does not have the tools or the expertise to decipher the hardware design in order to detect a change in the software/hardware interface. Information in the form of either documents or formal models is often not shared on line because of lacking IT infrastructure or organizational issues such as mutual distrust between competing vendors for example. Hence critical changes are not propagated in a timely manner.
As a result of these deficiencies, the design process becomes much longer, problems are uncovered at the tail end of the process at integration phase. Recovery is very costly and the resulting design is sub-optimal and often misses some of its goals in terms of target market window, cost, reliability or feature set.
Furthermore, the lack of architecture, structures, and standards for system design and system engineering in general constitutes a major obstacle for the development of systems and often cause significant waste in resources and time which in turn negatively impact the time to market and therefore profitability due to problems in integration of various parts of the system. For example, the lack of architecture, structures, and standards for Electronic System Level (ESL) design and system engineering in general is a major obstacle for the development of automation tools.
What may often worsen the above problems is that a diverse set of engineering tools are used in the process of system design, where each domain specialist is using a particular tool. Engineering tools typically represent a partial model of the design. Such models are formal in some sense—they can execute, emulate, or simulate on a computer, or have some well understood mathematical foundation. Some examples of this diverse set of engineering tools comprise, for example, SysML tools, such as Rhapsody®, which are used by system engineers to capture an abstract functional description of the design, Simulink® which is used by DSP, control, and algorithm designers to capture computational aspects of system components, reliability analysis tools, such as Relex®, which are used by reliability engineers to capture system possible failure modes and reliability predictions, structural modeling tools, such as Pro-Engineer® and SolidWorks®, which are used to model and construct the structural elements of a system, and analysis tools, such as ANSYS® and Abacus®, which are used to numerically analyze the mechanical and electromagnetic aspects of a system.
Such engineering tools can typically export their internal models to a domain specific format, often as a computer file. The formats tend to be all different, as are the underlying semantics of the different models, which make the sharing of information among various design teams and specialists even more difficult. Building on the examples above, the structural information captured in a SysML model is required for the reliability analysis process. The assumptions about input/output relationships in a control algorithm design must be consistent with the SysML representation of communication between components. Furthermore, certain properties of the overall system can not be observed in any of the design tools because they may constitute emergent properties that only show up at the full system level. For example, two control algorithms that operate flawlessly when observed independently may nonetheless oscillate due to a non-obvious feedback loop when these two control algorithms are coupled together using, for example, the system level communication model.
The conventional approaches to address the above problems have their own drawbacks. For example, Metropolis® introduces the concept of meta-modeling for system level design and focuses on a refinement methodology through the mapping of functionality to architecture in the presence of constraints. Nonetheless, Metropolis® does not address the bridging of semantics between different design tools. As another example, SPEEDS (SPEculative and Exploratory Design Systems Engineering) is targeting model exchange between tools, by virtue of each tool adhering to a common semantic framework. This is in contrast with the current invention which makes no assumptions on external tool compliance. Moreover, Model Integrated Computing (MIC) focuses on integrating multiple domain specific tools by generating tool exchange formats from a common semantic framework. These current approaches either fail to address the semantics bridging or require external tool compliance by imposing specific formats or semantics on external tools, and thus it may not be practical to adjust or replace the complete tool chains used in system designs given the commercial setting with so many existing and deeply engrained tools that are currently used.
Thus, it is an objective of various embodiments of the present invention to provide a consistent framework containing design requirements, specifications and project management data is proposed as a way to break through this barrier while preserving semantics of various external models without requiring external tool compliance.